wafer.space Community - Tons of DRC issues

While working on https://github.com/MidstallSoftware/aegis/pull/21, I've seen all of these DRC issues and I am stuck:

26-Apr-2026 21:54:06 | ERROR   | Violated rules are : {'M1.2b', 'V2.2a', 'M2.1', 'M4.2a', 'M1.2a', 'V1.1', 'M1.1', 'M3.2a', 'V2.1', 'M2.2a', 'M3.1', 'V1.3c', 'V1.2a'}

I'm not sure what I am doing wrong but it would be nice to have some help. I've been running my DRC via nix build .#checks.aarch64-linux.luna-1-gds-verify and producing the GDS via nix build .#luna-1-tapeout. (edited)

Try opening the gds in KLayout; KLAYOUT_PATH=$PDK_ROOT/$PDK/libs.tech/klayout klayout, then just open the file via the menu; you can then trigger the DRC by clicking run full drc in

1:24 a.m.

you might have to hit the rightmost one of these that says sky130a for me here (the drop-down button on the right edge of it) and select the option that isn't just "default".

1:25 a.m.

then maybe press that full Torx-shaped button with the T in the shape once after seelcting, before the DRC option in the main menu bar becomes available.

1:26 a.m.

You can then press on any individual line of the report and the offending segments show up in the layout view window as black lines; you can adjust colors and such on the right side of the report window.

namibj

You can then press on any individual line of the report and the offending segments show up in the layout view window as black lines; you can adjust colors and such on the right side of the report window.

Huh? What would that do?

2:49 a.m.

Shouldn't I have this information in the log I got from KLayout running through the GDS?

The Computer Guy

Shouldn't I have this information in the log I got from KLayout running through the GDS?

Oh yeah if you have the log file you should be able to open it and view, like this:

Huh?

run DRC (custom), unselect all (make sure you're not gonna overwrite your nice log), top right file -> open, select the log, enjoy.

3:01 a.m.

I'm assuming you don't want to search for the offending coordinates/shapes in the text files by hand, to try and make sense of what exactly the DRC log entries are blaming/complaining about.

Do I have to use the GUI for this?

The DRC complaints only narrow down to which cell, and I'm not sure if they blame specific instances of a cell or only "all".

3:08 a.m.

The engine itself only really operates on (polygonal, for efficciency, but it might as well be literal as the outcome wouldn't change, just the runtime/memory usage) rasterized/bitmap-view of the GDS layers at the native coordinate quantization "pixel size", as the rules rely heavily on performing boolean operations between/across layers to determine things. It unfortunately doesn't know what source shape caused the problem, only what edge/edge-pair (as in, location) caused the problem. If there are edges at that location from more than one layer you have to guess based on the rule's description which of the options it was.

The Computer Guy

Do I have to use the GUI for this?

Technically you can reason about the files without the GUI. Have you found the file yet?

I think so

3:11 a.m.

result-4/netlist.spice
result-4/v2spice.log
result-4/raw_netlist.spice
result-4/drc_output/contact.drc
result-4/drc_output/metal1.drc
result-4/drc_output/luna_1_metal4.lyrdb
result-4/drc_output/luna_1_via4.lyrdb
result-4/drc_output/metaltop.drc
result-4/drc_output/via1.drc
result-4/drc_output/layers_def.drc
result-4/drc_output/drc_run_2026_04_26_21_21_23.log
result-4/drc_output/luna_1_geom.lyrdb
result-4/drc_output/luna_1_metal5.lyrdb
result-4/drc_output/luna_1_via2.lyrdb
result-4/drc_output/luna_1_metal2.lyrdb
result-4/drc_output/metal5.drc
result-4/drc_output/metal2.drc
result-4/drc_output/luna_1_metal3.lyrdb
result-4/drc_output/luna_1_via3.lyrdb
result-4/drc_output/via2.drc
result-4/drc_output/luna_1_contact.lyrdb
result-4/drc_output/geom.drc
result-4/drc_output/via4.drc
result-4/drc_output/luna_1_via1.lyrdb
result-4/drc_output/luna_1_metal1.lyrdb
result-4/drc_output/via3.drc
result-4/drc_output/luna_1_metaltop.lyrdb
result-4/drc_output/metal3.drc
result-4/drc_output/metal4.drc
result-4/drc.log
result-4/gds_check.log

I think it might be one of the .drc files?

given it's named "output", I'd presume so.

3:12 a.m.

can you show the first few hundred bytes or so of one of them, I'd start with the rc_run_2026_04_26_21_21_23.log?

That file is quite small

3:13 a.m.

message.txt

4.65 KB

This is one of the drc result formats that I've encountered; I'm not sure if this is the one you'd have.

sky130_drc.txt

39.57 KB

Oh, that's the .lyrdb files I have

yeah I know it's not the same PDK

Yeah

3:15 a.m.

Though I plan on using Sky130 in the future heh

3:16 a.m.

There's a lot of V1.1 violations for Via1

3:16 a.m.

V1.1 : Min/max Via1 size . : 0.26µm

The Computer Guy

Oh, that's the .lyrdb files I have

this XML refers to the generator. This XML itself is a clean DRC result. You should see content in the XML if you have that format. I'd try grepping for a fragment of the XML that you'd expect to show up, like maybe the lydrc file as a string.

Huh the .drc files I have are python

The Computer Guy

V1.1 : Min/max Via1 size . : 0.26µm

if you violate that you're somehow creating vias that are not the size they should be, like, there's no room for options there, vias have exactly that size, and thus it's either some generator script thinking it knows better (unlikely unless you wrote something like that for this AegisFPGA), or somewhere a misconfig about coordinate system scaling.

Shouldn't OpenROAD have done that automatically in the way the PDK wanted?

The Computer Guy

Huh the .drc files I have are python

See if you find </report-database> at the end of any of those files

The Computer Guy

Shouldn't OpenROAD have done that automatically in the way the PDK wanted?

sure, should, but vias don't tend to just malform themselves.

namibj

See if you find </report-database> at the end of any of those files

$ grep -r "</report-database>" result-4/drc_output
result-4/drc_output/luna_1_metal4.lyrdb:</report-database>
result-4/drc_output/luna_1_via4.lyrdb:</report-database>
result-4/drc_output/luna_1_geom.lyrdb:</report-database>
result-4/drc_output/luna_1_metal5.lyrdb:</report-database>
result-4/drc_output/luna_1_via2.lyrdb:</report-database>
result-4/drc_output/luna_1_metal2.lyrdb:</report-database>
result-4/drc_output/luna_1_metal3.lyrdb:</report-database>
result-4/drc_output/luna_1_via3.lyrdb:</report-database>
result-4/drc_output/luna_1_contact.lyrdb:</report-database>
result-4/drc_output/luna_1_via1.lyrdb:</report-database>
result-4/drc_output/luna_1_metal1.lyrdb:</report-database>
result-4/drc_output/luna_1_metaltop.lyrdb:</report-database>

great, so that's probably the files of interest.

3:21 a.m.

result-4/drc_output/luna_1_via1.lyrdb?

3:21 a.m.

If it's not secret ofc

Oh, that's 56kb

yeah a bunch of your errors

  <category>
   <name>V1.1</name>
   <description>V1.1 : Min/max Via1 size . : 0.26µm</description>
   <categories>
   </categories>
  </category>
  <category>
   <name>V1.2a</name>
   <description>V1.2a : min. via1 spacing : 0.26µm</description>
   <categories>
   </categories>
  </category>
  <category>
   <name>V1.2b</name>
   <description>V1.2b : Via1 Space in 4x4 or larger via1 array : 0.36µm</description>
   <categories>
   </categories>
  </category>
  <category>
   <name>V1.3a</name>
   <description>V1.3a : metal1 overlap of via1 &gt;= 0.0</description>
   <categories>
   </categories>
  </category>
  <category>
   <name>V1.3c</name>
   <description>V1.3c : metal1 (&lt; 0.34um) end-of-line overlap. (Applies to all &lt; 0.34µm wide Metal lines,
                    excluding Metal branches shorter than 0.28µm.) : 0.06µm</description>
   <categories>
   </categories>
  </category>
  <category>
   <name>V1.3d</name>
   <description>V1.3d : If metal1 overlap via1 by &lt; 0.04um on one side, adjacent metal1 edges overlap. : 0.06µm</description>
   <categories>
   </categories>
  </category>
  <category>
   <name>V1.4a</name>
   <description>V1.4a : metal2 overlap of via1 &gt;= 0.01 um</description>
   <categories>
   </categories>
  </category>
  <category>
   <name>V1.4b</name>
   <description>V1.4p : metal2 (&lt; 0.34um) end-of-line overlap. (Applies to all &lt; 0.34µm wide Metal lines,
                    excluding Metal branches shorter than 0.28µm.) : 0.06µm</description>
   <categories>
   </categories>
  </category>
  <category>
   <name>V1.4c</name>
   <description>V1.4c : If metal2 overlap via1 by &lt; 0.04um on one side, adjacent metal2 edges overlap. : 0.06µm</description>
   <categories>
   </categories>
  </category>

if you open the GDS you can just load it or you can look at it's contents more programmatically

3:23 a.m.

yeah that's just the header/legend

I have the GDS open on my laptop in KLayout

you can feed this file in then

How do I open the lyrdb file?

can you show me the menu bar? Or rather, what's teh right most main menu bar name?

actually, try "Tools -> Marker Browser"

Ah cool, that looks promising

you might want to point klayout at the PDK path though

3:26 a.m.

e.g. KLAYOUT_PATH=$PDK_ROOT/$PDK/libs.tech/klayout klayout -e

3:26 a.m.

(if using ciel)

yeah you select a row possibly after expanding a folded one, and while a row is selected/highlighted, you'll see them highlighted as lines in the layout view window

3:28 a.m.

(SerDes? Noice....)

Cool, I see it

3:29 a.m.

https://github.com/Midstall/aegis/pull/21/changes#diff-297415984077469f4bd6bc71cb8e9dc8615316b804cca6335ca1b89eecaaccf1 I'll have to change something here I think to fix it

fix: verification by RossComputerGuy · Pull Request #21 · Midstal...

3:30 a.m.

I'm not exactly sure what I need to do to fix this

Ah, OpenROAD stopped short on iterating. I wonder if increasing the routing iterations would fix a lot of problems.

The Computer Guy

Ah, OpenROAD stopped short on iterating. I wonder if increasing the routing iterations would fix a lot of problems.

auto routing "gave up" before finishing into a state where it passed LVS to the point where it at least thinks it has finished routing the entire netlist it was tasked with?

namibj

auto routing "gave up" before finishing into a state where it passed LVS to the point where it at least thinks it has finished routing the entire netlist it was tasked with?

Idk, I've tried doing LVS but I skipped LVS because it caused the DRC + LVS job to run for like 30 hours

LVS comes after DRC (personally; this is not inherently strict but some DRC fails will result in bogus LVS)

3:47 a.m.

note you probably want to exempt "casual" LVS from operating at granularity below the standard cell "abstract block with ports and nominal behavior/named-behavior", at least in usual design loop.

Oh

no sadly don't know how

This is my first design so idk how either lol

I'd suggest you tell openroad to not give up so soon; it might have been tuned for tiles that are substantially less packed vs. your FPGA.

Yeah

The Computer Guy

This is my first design so idk how either lol

Like I read mention of that yesterday but don't even remember for which tool let alone in what docs.

3:51 a.m.

(And I don't need to for my tiny 1x2 analog tile on ttsky26a.)

3:53 a.m.

(....can you link the actual analog PLL that is mentioned by the code in your repo? I'd like to look at it this evening a little bit for some dose of inspiration.)

namibj

(....can you link the actual analog PLL that is mentioned by the code in your repo? I'd like to look at it this evening a little bit for some dose of inspiration.)

https://github.com/Midstall/aegis/blob/f375157ff1c4b5b1cfcac49411b3b2164238857a/ip/lib/src/components/analog/pll.dart

aegis/ip/lib/src/components/analog/pll.dart at f375157ff1c4b5b1cfca...

Open source FPGA silicon. Contribute to Midstall/aegis development by creating an account on GitHub.

The Computer Guy

https://github.com/Midstall/aegis/blob/f375157ff1c4b5b1cfcac49411b3b2164238857a/ip/lib/src/components/analog/pll.dart

No I found that. But that's not doing PLL. It's wrapping, sure, but it's not doing PLL.

namibj

No I found that. But that's not doing PLL. It's wrapping, sure, but it's not doing PLL.

PLL is some sort of oscillating thingy that can be somehow controlled, and is somehow phase-compared to some kind of reference, and what makes it PLL is that these two things (the "controllable oscillator" and the "oscillator [output] phase comparing to reference") are wired into a control loop.

4:11 a.m.

If correctly designed/configured, it then has to actually manage to lock to deserve the title of "Phase-Locked Loop".

4:11 a.m.

(I don't want to keep you from finishing the FPGA into a functional state in time for the WS Run2 deadline.)

namibj

PLL is some sort of oscillating thingy that can be somehow controlled, and is somehow phase-compared to some kind of reference, and what makes it PLL is that these two things (the "controllable oscillator" and the "oscillator [output] phase comparing to reference") are wired into a control loop.

Yeah, I'm just wrapping the one from the PDK for simplicity

....there is one in the PDK? (I tried and failed to find one, but maybe I searched wrong)

namibj

....there is one in the PDK? (I tried and failed to find one, but maybe I searched wrong)

gf180mcu_fd_pr__pll.sym lol

....that's a symbol, not an actual thing. It's just an abstract placeholder for a schematic.

Oh

@Leo Moser (mole99) - Dunno if you have any ideas about this?

The vias are indeed of a fixed size, so the only issues I can think of are that the manufacuring grid is not set correctly (everything is scaled by a factor of 5), or there is some other setup issue. I suggest checking the wafers.space gf180mcu-project-template against your custom set up.

I've been checking what I have vs the template. I might've forgotten about PDN lol

Hmm, 0 violations in OpenROAD's DRC but KLayout says like 3.5k (edited)

@Tim 'mithro' Ansell which DRC is more believable?

You need to pass KLayout DRC in order to tape out. OpenROAD only has an abstract view of the cells and routing.

Oh. Most of my KLayout DRC violations are on metal1, 2.2k.

I don't think I'll be able to get the early bird deadline. Everything I try to do does not fix the DRC violations. I'm not sure what I am doing wrong and idk how to fix the violations.

You should be able to buy a slot even if you don't have the design ready yet.

6:44 p.m.

As for the DRC violations, if you could share your current layout, I can take a quick look to see what's going on.

Leo Moser (mole99)

As for the DRC violations, if you could share your current layout, I can take a quick look to see what's going on.

Like the GDS file?

Leo Moser (mole99)

You should be able to buy a slot even if you don't have the design ready yet.

Cool, hopefully I can do that soon.

The Computer Guy

Like the GDS file?

Yes

Leo Moser (mole99)

Yes

Cool, here you go

luna_1.gds

256.92 MB

It looks to me like all the metal layers have been removed from the standard cells and merged at the top level. This appears to be result in power shorts and very thin metal1 maybe due to resizing. See screenshot. I don't think that this will be easy to extract with open source tools.

bailey

It looks to me like all the metal layers have been removed from the standard cells and merged at the top level. This appears to be result in power shorts and very thin metal1 maybe due to resizing. See screenshot. I don't think that this will be easy to extract with open source tools.

Fun, lemme try something

10:17 p.m.

Gonna drop the pkgs/aegis-tapeout/scripts/drc_repair.py script

bailey

It looks to me like all the metal layers have been removed from the standard cells and merged at the top level. This appears to be result in power shorts and very thin metal1 maybe due to resizing. See screenshot. I don't think that this will be easy to extract with open source tools.

I have this now btw

luna_1.gds

73.28 MB

The Computer Guy

I have this now btw

Looks like the standard cell rows are missing filler cells. Can you confirm?

bailey

Looks like the standard cell rows are missing filler cells. Can you confirm?

I think I see standard cells, what exactly are standard cell rows?

4:14 a.m.

Ah, sounds like I need to run filler_placement?

1

bailey

Looks like the standard cell rows are missing filler cells. Can you confirm?

Cool, I've added that in

luna_1.gds

71.44 MB

4:28 a.m.

KLayout is getting a little slow

Better, but still not seeing power grid connections to all the macros or cell rows. (edited)

Weird, I did do the PDN stuff

Are you using librelane or OpenROAD directly?

OpenROAD directly and orchestrated through Nix.

4:35 a.m.

The OpenROAD scripts are generated from Dart.

4:35 a.m.

Do I need to do define_pdn_grid?

aegis-top-pnr-luna_> [INFO PDN-0001] Inserting grid: macro_grid - io_fabric/lut_fabric/tile_325
aegis-top-pnr-luna_> [INFO PDN-0001] Inserting grid: macro_grid - io_fabric/lut_fabric/tile_326
aegis-top-pnr-luna_> [INFO PDN-0001] Inserting grid: macro_grid - io_fabric/lut_fabric/tile_327
aegis-top-pnr-luna_> [INFO PDN-0001] Inserting grid: macro_grid - io_fabric/lut_fabric/tile_328
aegis-top-pnr-luna_> [INFO PDN-0001] Inserting grid: macro_grid - io_fabric/lut_fabric/tile_329
aegis-top-pnr-luna_> [INFO PDN-0001] Inserting grid: macro_grid - io_fabric/lut_fabric/tile_33
aegis-top-pnr-luna_> [INFO PDN-0001] Inserting grid: macro_grid - io_fabric/lut_fabric/tile_330
aegis-top-pnr-luna_> [INFO PDN-0001] Inserting grid: macro_grid - io_fabric/lut_fabric/tile_331

This seems promising

TBH, what you're are attempting is beyond my level of experience. What I've seen in the past, is that hard macros have their own power grid with the top metal layer one lower than the max. (metal4 in this case). Since metal 4 is a vertical layer, you should be able to have the power grid for the macros, connect directly to metal1 through a metal1-via-metal2-via2-metal3-via3-metal4 stack at the metal1 power rail for each cell row. How many metal4 power rails you use depends on the width of the macro. Since you need metal4 routing over the macros, you'll want to be careful where you place the power rails. Some of the macros currently have metal5, and while that may be doable, I suggest the top metal routing layer be limited to metal4. Next you need to design your top level power gird so that both power and ground horizontal metal5 power lines intersect with all the hard macros. The top power grid will be vertical metal4 and horizontal metal5. In this case, metal4 power rails are not generally routed over macros that already have metal4 power rails. Another consideration is the power connections for the standard cell rows placed between the macros. Normally, the metal1 power rails in these standard cells is connected to metal4 power rails at the top level, but in your case, these rows are narrow and may not intersect with the power grid. You may want to consider setting these regions as no cell placement. Also noticed that you are using fill cells and not fillcap cells. fillcap cells add capacitance between the power and ground lines for better stability.

Alright. Thank you for the help though.

1

I can only repeat what bailey said. The power connections are missing, and decap cells would be better than fillcaps.

7:14 a.m.

Independent of that, your layout is missing a padring and a sealring. This is your interface to the outside world.

7:14 a.m.

Here is your layout alongside the gf180mcu project template.

7:15 a.m.

I would recommend implementing the gf180mcu project template and comparing the output with your setup.

Leo Moser (mole99)

Independent of that, your layout is missing a padring and a sealring. This is your interface to the outside world.

Cool, will see what that can do for me. Thanks. I'm not really familiar with LibreLane or any of this stuff so this has been quite new for me. Hopefully I can integrate some of this trial and error into my asix and harbor repos which help out for ASIC/FPGA design/dev.

1